What are the files in resources/native? Do we need to keep them in the repo?

Once again, LLM explains it better then I would. 🙂

What they are:

These are pre-compiled native JNI libraries built from the https://github.com/databricks/zerobus-sdk-rs. The Java SDK calls into these via JNI for high-performance ingestion.

Why they're in the repo:

1. User convenience - Users get a working SDK without needing Rust toolchain or building native code
2. Maven Central distribution - The JAR bundles these libraries, and NativeLoader.java extracts them at runtime to a temp directory
3. Cross-platform support - Different binaries for each OS/arch

Do we need to keep them?

Yes, unless we change the distribution model to either:

• Download natives at runtime (adds complexity, network dependency)
• Require users to build natives themselves (bad UX)
• Publish natives as separate artifacts (more complex release process)

The current approach (bundled in JAR) is the standard pattern for JNI libraries (similar to how SQLite JDBC, RocksDB Java, etc. distribute their natives).

What are the files in resources/native? Do we need to keep them in the repo?

Once again, LLM explains it better then I would. 🙂

What they are:

These are pre-compiled native JNI libraries built from the https://github.com/databricks/zerobus-sdk-rs. The Java SDK calls into these via JNI for high-performance ingestion.

Why they're in the repo:

1. User convenience - Users get a working SDK without needing Rust toolchain or building native code
2. Maven Central distribution - The JAR bundles these libraries, and NativeLoader.java extracts them at runtime to a temp directory
3. Cross-platform support - Different binaries for each OS/arch

Do we need to keep them?

Yes, unless we change the distribution model to either:

• Download natives at runtime (adds complexity, network dependency)
• Require users to build natives themselves (bad UX)
• Publish natives as separate artifacts (more complex release process)

The current approach (bundled in JAR) is the standard pattern for JNI libraries (similar to how SQLite JDBC, RocksDB Java, etc. distribute their natives).

Okay but what about MacOS?

What are the files in resources/native? Do we need to keep them in the repo?

Once again, LLM explains it better then I would. 🙂

What they are:

These are pre-compiled native JNI libraries built from the https://github.com/databricks/zerobus-sdk-rs. The Java SDK calls into these via JNI for high-performance ingestion.

Why they're in the repo:

1. User convenience - Users get a working SDK without needing Rust toolchain or building native code
2. Maven Central distribution - The JAR bundles these libraries, and NativeLoader.java extracts them at runtime to a temp directory
3. Cross-platform support - Different binaries for each OS/arch

Do we need to keep them?

Yes, unless we change the distribution model to either:

• Download natives at runtime (adds complexity, network dependency)
• Require users to build natives themselves (bad UX)
• Publish natives as separate artifacts (more complex release process)

The current approach (bundled in JAR) is the standard pattern for JNI libraries (similar to how SQLite JDBC, RocksDB Java, etc. distribute their natives).

Okay but what about MacOS?

I've managed to add both MacOS platforms, thanks!